home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / CODING / CPP / HUGEAR.ZIP / README.TXT < prev   
Encoding:
Text File  |  1994-11-28  |  6.3 KB  |  108 lines
  1. This is an implementation of huge arrays and huge vectors using templates and
  2. the Borland container class library. Here are the features:
  3.  
  4. 1: The code is for 16 bit platforms, DOS, DPMI16, WINDOWS, for Borland C++ 4.02 .
  5.  
  6. 2: Huge arrays provide arrays of items that go beyond 64K in the 16 bit world 
  7.    to access all of available memory.
  8.  
  9. 3: The code is a direct modification of Borland's arrays.h, vectimp.h, and
  10.    alloctr.h . These files are harrays.h, hvectimp.h, and halloctr.h . To
  11.    use huge arrays, just include the file harrays.h in your source. To use
  12.    huge vectors just include the file hvectimp.h in your source. The other
  13.    file(s), as well as files in Borland's container class library will be
  14.    included automatically.
  15.  
  16. 4: The names for the huge arrays and the huge vectors are the exact same
  17.    names you would use for normal arrays and vectors in Borland's container
  18.    class library but with the word "Huge" preceding the Array of Vector in the
  19.    name. For instance instead of instantiating a TArrayAsVector object you
  20.    would instantiate a THugeArrayAsVector object. Instead of instantiating 
  21.    a TVectorImp you would instantiate a THugeVectorImp. The same naming 
  22.    conventions go for the array and vector iterators. The naming conventions
  23.    for Borland 3.1, accessible by defining BI_OLDNAMES before including the
  24.    container class library header file(s), is not supported for this 
  25.    implementation.
  26.  
  27. 5: There is no conflict between this huge array implementation and any of the
  28.    other container class libraries.
  29.  
  30. 6: Both direct and indirect arrays and vectors are fully supported.
  31.    For direct arrays you are still adding just the object, not a huge object.
  32.    For the indirect arrays and vectors you are still passing in normal pointers
  33.    to objects, not huge pointers to these objects. It is the array or
  34.    vector that is "huge" not the objects themselves.
  35.  
  36. 7: For both direct and indirect objects the [] operator to access these objects
  37.    return a "huge reference" rather than just a reference. For direct containers
  38.    this is a huge reference to the actual object ie. T __huge & , while for
  39.    indirect containers this is a huge reference to the pointer to the object
  40.    ie. T * __huge & . This parallels the normal container classes case.
  41.  
  42. 8: For direct containers, other functions other than the [] operator that pass back
  43.    references or pointers to the containers now pass back huge references or
  44.    huge pointers to these containers. These include the things like the
  45.    ++ iterator operators, the FirstThat and LastThat functions etc. This
  46.    parallels the normal container classes.
  47.  
  48. 9: For indirect containers, other functions other than the [] operator above
  49.    pass back the actual pointer to the object. This is a normal pointer, not
  50.    a huge pointer ( see 6: above ). This parallels the normal container classes.
  51.  
  52. 10: Sizes for these arrays and vectors are no longer int or unsigned int
  53.    but long and unsigned long respectively. Functions that used to pass back the
  54.    2 byte quantities now pass back the 4 byte quantities ie. ArraySize and    
  55.    GetItemsInContainer . Array and vector sizes are initialized
  56.    in terms of long and unsigned long sizes rather than int and unsigned int
  57.    respectively.
  58.  
  59. 11: This implementations uses internally the standard library functions
  60.    "farmalloc" and "farfree" whereas the standard container classes use the
  61.    C++ "new" and "delete" operators. The "new" and "delete" operators could
  62.    not be used since they take "size_t" sizes and "size_t" in the 16 bit
  63.    world is an unsigned int. You do not have to be concerned about this
  64.    unless you use your own managed memory array or vector, in which case
  65.    look at halloctr.h . Otherwise this knowledge is transparent.
  66.  
  67. 12: Because "farmalloc" and "farfree" is used in place of "new" and "delete"
  68.    an exception is thrown if memory could not be allocated. The name of the
  69.    exception is THugeXAllocation . It is located in halloctr.h, which is
  70.    automatically included when you include harrays.h or hvectimp.h . The
  71.    exception has one public member, "unsigned long size", which is the size
  72.    of the allocation on which farmalloc failed. The exception could occur
  73.    when:
  74.  
  75.          You initially allocate an array or vector of a certain size in the
  76.              constructor.
  77.          Use the copy constructor to construct an array or vector from another
  78.              array or vector.
  79.          Assign an array or vector to your present array or vector.
  80.          Add or AddAt an object to your array or vector.
  81.  
  82.    You can catch this exception and deal with as you like in the normal way.
  83.  
  84. 13: This is NOT, repeat NOT, an official implementation by Borland and is in
  85.    no way connected with them. My name is Edward Diener, my Compuserve ID is
  86.    70304,2632 . I will be happy to hear of any problems you have with this
  87.    implementation in order fix things if anything is wrong. However you are
  88.    largely on your own when it comes to understanding huge arrays and vectors.
  89.    I have made the implementation as transparent as possible and it parallels
  90.    as closely as I can make it the normal array and vector container class
  91.    implementation. You have the source code and so can modify it for your 
  92.    own purposes but please, if you re-post it for any reason for other users
  93.    ask Borland's permission first. I have asked and received Borland's 
  94.    permission to post this code for other users. I do not have Borland 4.5
  95.    yet so I have no idea whether this will work with Borland 4.5 . If when
  96.    I receive 4.5 there is still no support for huge arrays and vectors I may
  97.    do the implementation for 4.5 .
  98.  
  99. 14: This was originally done because I wanted to access arrays greater than
  100.    64K for a personal project I am doing. I am not in love with "huge"
  101.    keywords, segmented architecture etc. I will be only too happy to move
  102.    to the 32 bit world and leave all that nonsense behind. However I use
  103.    Borland's Paradox Engine and Database Frameworks and am beginning to use
  104.    the Database Engine, and both are still only for the 16 bit world. I 
  105.    eagerly look forward to Borland releasing their Database Engine for the
  106.    32 bit world, hopefully for both WIN32 and DPMI32, at which time I will
  107.    glad leave the limitations of the 16 bit world behind.
  108.